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Anecdotes 


The Beginnings of TECO 


Dan Murphy 


I came up with the name TECO in 1962 while sitting 
in Ye Hong Guey, my favorite restaurant in Boston’s 
Chinatown during my undergraduate years at the Mas- 
sachusetts Institute of Technology. I had been working 
on a little program to help me write other programs, a 
common activity in the day when a computer (the Dig- 
ital Equipment Corporation PDP-1) would be delivered 
with almost no software. My program had gotten to the 
point that it needed a name, so my friend Pete Peterson 
and I were kicking around possibilities and their 
acronyms. 

Years later, TECO would be known to mean Text 
Editor and Corrector and so described in its documenta- 
tion. However, the original meaning—the one we came 
up with that night at the corner of Oxford and Beach 
streets—was Tape Editor and Corrector. 


Interactive computer use on the PDP-1 

We used the term ‘‘tape’’ because punched paper 
tape was the only medium for the storage of program 
source on our PDP-1. There was no hard disk, floppy 
disk, magnetic tape (magtape), or network. There 
was no operating system, only the paper tape reader 
and punch and a console typewriter. The paper tape 
reader was fast (or so it seemed at the time), reading 
300 characters per second. The punch was consider- 
ably slower at 20 characters per second. The console de- 
vice was an office-style electric typewriter that had been 
interfaced to the PDP-1 for character-at-a-time input 
and output. 

The PDP-1 was the first computer built and sold by 
DEC and thus the leading edge of the minicomputer 
revolution. It was anything but ‘‘mini’’ by today’s stan- 
dards, however; it occupied several tall cabinets in its 
minimum configuration. All that, and it had a main 
memory of only 4,096 18-bit words (effectively 8 
Kbytes). This was core memory made of tiny magnetic 
toroids strung on thin wires in a 3D mesh. It had a 
cycle time of 5 microseconds. The processor executed 
most instructions in two cycles (10 microseconds)—one 
cycle to fetch the instruction from memory, and the 
second to load and/or store the memory operand. 
Some instructions did not reference memory and so 
required only one cycle. 

All this notwithstanding, it was exciting to actually 
be able to sit at the console and use the computer inter- 
actively. My prior experience was with mainframe class 
machines like the IBM 709 or 7090. Those required pre- 
paring a program on punched cards, submitting the 
deck to the computer center for a batch run, and get- 
ting a paper listing of the results the next day. With 
the PDP-1, the code-compile-debug cycle was shortened 
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from hours to minutes. I could do it several times on 
the machine in a one-hour session. 

In a smart move for a young corporation, DEC had 
donated a PDP-1 to the Research Laboratory for Elec- 
tronics (RLE) at MIT, and it was sitting in a room 
more-or-less available for anyone, including undergrad- 
uates, to play with. There were soon many takers. Be- 
cause only one person could be using the PDP-1 at a 
time, computer time quickly became scarce, and it 
was still necessary to do as much program preparation 
as possible offline. We did this with Frieden Flexo- 
writers, typewriter-like devices with a paper tape reader 
and punch. Programs had to be handwritten first 
because editing capabilities on the Flexowriter were 
nonexistent. The most you could do was nullify a pre- 
viously punched character by backing up the tape 
punch and over punching the same line. 

Paper tape was more convenient than punched cards 
in some ways. It was lighter than cards for a given num- 
ber of lines of program, and if you accidentally dropped 
it, it did not shuffle all your lines of code. This was also 
its biggest weakness. When you needed to modify a 
program—add, change, or delete a few lines—you 
could not just replace those lines as you did with the 
cards; you had to punch a whole new tape. Hence, edit- 
ing on the Flexowriter was a painstaking process of 
reading an existing source tape and simultaneously 
punching a new one, while stopping at each point 
where changes were to be made to type new material 
and skip over unwanted old material. 

It was also possible to edit on the computer, which 
is what we did while debugging and recompiling dur- 
ing our slots of computer time. The editor on the 
PDP-1 had a simple line-oriented interface that let 
users step through an existing paper tape, adding or 
replacing lines to produce a new generation of the 
source. Using this editor consumed precious com- 
puter time, however, and it used the whole computer 
to do a “‘simple’’ task, so it was known as Expensive 
Typewriter. 

That Expensive Typewriter could only add, delete, or 
replace entire lines of text annoyed me considerably. It 
was a bothersome fact of punched cards that making 
any change on a line required retyping that whole 
line on a new card, and I didn’t see why that limitation 
needed to exist for this new medium where there was 
no physical separation between one line and the next 
other than the carriage-return character. 


The birth of TECO 
Thus, I decided to write a program that, like Ex- 
pensive Typewriter, would let me copy a paper tape 
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while making changes along the way and 
would let me make those changes character 
by character. Accordingly, the first few 
commands would include these types of 
functions: 


delete a character, 
delete a line (it was still convenient to 
work on lines sometimes), 

e insert text (any amount from one charac- 
ter to multiple lines), and 

e search for text at the point where you 
wanted to make changes. 


TECO was not initially intended to be an 
interactive, online editor. Because of the scar- 
city of computer time, online editing was still 
considered somewhat squanderous, and we 
really did not want to wait until our next 
time slot to get the next source revision 
ready. 

Therefore, TECO was intended to be used 
offline, on the Flexowriter, where we would 
prepare a separate paper tape with the com- 
mands needed to edit our existing source 
tape. As people often say, “it seemed like a 
good idea at the time.’’ In other words, the 
idea was to hand-mark changes on your 
source listing and enter the TECO com- 
mands necessary to make those changes on 
the Flexowriter (i.e. find a spot, delete, in- 
sert, move on). Then, when our computer 
time came, we would load TECO and read 
in our commands tape, so TECO could 
read our old source tape and quickly 
punch a new one. 

Hence, in the beginning, TECO was a lan- 
guage for describing changes to a source pro- 
gram or, more generally, a stream of text. 
This turned out to be its real power as time 
passed and its evolution continued. 


TECO becomes interactive 

In the short term, however, offline com- 
mand preparation proved to be impractical. 
It was impossible for most ordinary mortals, 
myself included, to consistently prepare 
command tapes that would work right. Like 
any other program, they would have bugs 
that would only become evident while on 
the computer. Thus, I added a mode to 
TECO early on that would dispense with 
reading the command tape first and simply 
let us enter commands at the console type- 
writer. Needless to say, this was an entirely 
different experience. We could enter one or 
a few commands, make sure the result was 
right, and then move on. 
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Although quite interactive, TECO was not 
a screen editor at this point. Although our 
PDP-1 did have a CRT display device, neither 
the paradigm nor the code existed for dis- 
playing text. Hence, source was kept on 
paper printouts, and editing online meant 
looking at a few lines at a time typed out 
on paper. 

With interactive editing, a number of 
other enhancements were soon required. It 
quickly became clear that moving through 
a source tape in only one direction was still 
awkward. An especially easy, but painful mis- 
take would be to mistype a search command 
so that the text you wanted would not be 
found and the copying would continue to 
the end of the tape. To solve this problem, I 
decided it would make sense to read a 
chunk of the source into memory where a 
number of edits could be made before com- 
mitting it to the new paper tape. The natural 
unit for this was one typewritten page. Most 
sources were paginated to this size because 
we were using letter-size fanfold paper stock 
in the Flexowriters and console typewriter. 

This was a big help. The usual search was 
limited to the current page, so a failed search 
was no problem. Just go back to the top of 
the page and try again. Plus, we could make 
some changes, see how they looked, and if 
still not right, do some further edits. 

Page-at-a-time editing required new com- 
mands for keeping track of the location that 
editing would take place (the point), for mov- 
ing to the next page or to the end of the tape, 
and for searching that was not limited to the 
current page. This search still carried the risk 
of going too far, but since it was used less 
often and only to get you to the right page, 
that risk was much lower. 

You might ask, why only one page at a 
time? Why not read in the whole source 
tape? As I noted earlier, our PDP-1 had a 
total memory component of about 8 Kbytes, 
and that had to hold the entire TECO pro- 
gram as well as whatever text was being 
edited. It was not until many years later 
that memories became large enough that 
yanking in the whole file became practical 
and routine. 

One enhancement in that direction be- 
came possible when the RLE PDP-1 had a 
swapping drum added to it. Although this de- 
vice was not large enough to serve as perma- 
nent storage for programs or sources, it was 
fast and could be used to work around the 
limited main memory size. For TECO, I 
implemented a kind of paging mechanism 
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Anecdotes 





Alleged Patent Infringement 


As simple as it seemed, even at the time, this method 
of command processing became the subject of a patent 
infringement case some years later. This was in the late 
1980s, and | was working for DEC in the VAX/VMS 
group. One day, | got a call from someone in the DEC 
legal office. It seems that IBM was being sued by 
some small company because of alleged patent in- 
fringement by the IBM PC. Some basic programming 
techniques were asserted as patented IP by this com- 
pany, and in looking to defend itself, IBM had done a 


search for prior art. One of the issues was character- 
based command dispatching, and somehow, IBM 
found TECO, which was originally implemented years 
before the claims of this challenger. IBM identified me 
as the original implementer, traced me to DEC, and 
contacted the DEC legal department to ask for assis- 
tance. | consulted with some IBM attorneys and was 
looking forward to a full-blown trial. | never got the 
call though, so | presume the case was settled well 
short of that. 











that allowed the main editing buffer to be 
many times larger than could fit in memory. 
I would draw on some of these paging ideas a 
few years later in the implementation of 
other multiuser systems culminating in 
TENEX and TOPS-20."? 

Punched paper tape remained in common 
use through at least the late 1960s on a num- 
ber of systems, but TECO supported other 
media almost as soon as it became available 
on any machine we used. One of the other 
PDP-1s at MIT had a magnetic tape drive, 
and I quickly added a magtape driver to 
TECO. Again, there was no operating system, 
or even common I/O libraries at that time, so 
each program had separate commands and 
I/O routines added for each device. 

Magtape was never practical for program 
storage, of course, even though it was won- 
derfully fast compared to paper tape. Much 
better was DECtape (or MicroTape), the 
block-addressable small-reel tape system 
eventually added to the PDP-1 and available 
on all DEC systems for many years. DECtape 
had a basic file system that supported a mod- 
est number of named files on each reel and 
the ability to rewrite files any number of 
times. This required TECO to grow the ability 
to open a file by name, not just yank a stream 
from a serial input device. 

Even when timesharing and disk-based 
file systems came into common use, TECO 
editing continued to be a page at a time for 
the most part. Conservative memory use 
was still important, and for all its power, 
TECO was economical to run. 


The TECO language 

I did not give much thought to the 
TECO’s “human interface” design at the be- 
ginning. The concept really didn’t exist 
around program tools at that point. The 
most commonly used interactive program 
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was the DDT debugger,’ and it had a set of 
single-letter commands with numeric argu- 
ments preceding. For example, to examine 
location 123 in your program, you would 
type 123/. DDT would act immediately on 
the slash and print the contents, so the line 
would then appear as 123/ lac foo. TECO fol- 
lowed that form with commands such as 


5d, meaning delete five characters; 

3c, Meaning move forward three char- 
acters; 

101, meaning move forward 10 lines; 

2k, meaning kill (delete) two lines; and 
iTEXT<term>, Meaning insert “TEXT,” or 
everything from the initial i to the special 
text termination character. 


As I noted earlier, I based the initial design 
of the TECO commands on entering them 
offline, but they continued to work well 
when interactive use became the rule. (See 
the sidebar for an interesting side note on 
character-based command dispatching.) 

From that relatively simple start, I went on 
to add further enhancements. Some of them 
were around making the language more con- 
sistent and general. For example, we did not 
need a separate command to move the 
pointer in reverse (the original r command); 
a negative argument to the character-move- 
forward command was quite natural. The 
same applied to commands that operated 
on lines—-31 meant move backward three 
lines, and -5k meant kill the preceding five 
lines. 0 (zero) meant the current line, so 01 
meant to move to the beginning of the cur- 
rent line. A number of simple constructs 
quickly became a habit for any TECO user, 
such as using 0kk to kill all the current line 
regardless of where the pointer is on it. 
(TECO uses the convention that the default 
argument is 1 for most commands.) 
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TECO becomes a programming language 

By late 1962, TECO had about the level of 
capabilities that simple editors would have 
for years to come, but TECO’s development 
didn’t stop there. Many of the subsequent 
enhancements were done simply because 
something occurred to me that I could easily 
do or someone suggested something, and it 
seemed like a cool idea. Our mindset was 
that cool ideas were fun to pursue, even if 
we couldn’t think of a practical use or need 
right away. 

More significant additions—the ones that 
began to give TECO some power as a pro- 
gramming language or text engine—included 
text buffers and the looping construct. TECO 
handled simple program modification fairly 
well at that point, but it did not offer a way 
to do significant restructuring (e.g., move a 
sizeable amount of text from one place to an- 
other or replicate a segment of text a number 
of times). To provide this, I added the con- 
cept of text variables—that is, a variable 
that would hold an arbitrary section of text. 
The command to move a range of text into 
a text variable was x. (I was running low on 
unused letters by then.) Its prefix argu- 
ment(s) identified a range of text in the 
buffer in the same way as the k command, 
and the single letter following the x was the 
variable name from the set a-z, 0-9. g (get) 
was used to copy the contents of a text vari- 
able into the main buffer at the editing 
point and could be used any number of 
times to replicate copes of the text. Despite 
the lack of a mnemonic association for x, it 
quickly came to seem natural, almost intu- 
itive. To x something became as easily spo- 
ken and understood by TECO users as 
“store’’ would have been. 

Then, given that we had the ability to store 
any text in a variable, I implemented a com- 
mand to execute a text variable as a TECO 
command string. An optional argument 
could be given in the form of a preceding ex- 
pression. Thus, TECO came to have a form of 
macro or callable function, and it followed 
from the original concept that a concise 
string of text would represent commands to 
modify other text. 

Around that same time, I also found that I 
wanted to be able to make repetitive and sys- 
tematic changes to the source text. This 
included simple cases like changing all occur- 
rences of “foo” to “‘fie’”’ (which would later be 
supported by the replace command) and 
things beyond simple search and replace, 
such as “find every line with ‘foo’ in it and 
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add a comment at the end.” This gave rise 
to the original loop construct: ( commands 
boolean ; commands ). 

The loop would be executed zero or more 
times until the test was false. A search variant 
was available that returned true only if the 
text was found, so search and modify loops 
were straightforward. The loop-begin and 
loop-end commands appeared as parentheses 
with a dot in the middle on the PDP-1. Sub- 
sequent ASCII-based versions of TECO used 
angle brackets for this purpose. 

Integer variables were also added around 
this time, again from the single-letter set a-z, 
0-9. u (use) would store its argument into 
the variable, and gq (quantity) would stand 
as the stored value in an expression. The 
same variable name could have both a text 
and numeric value; the command deter- 
mined which was being referenced. Because 
simple arithmetic expression were accepted, 
a loop to run, say, five times could be writ- 
ten as 


5ua 
( qa; commands ga-1lua ) 


Spaces and line breaks were not syntacti- 
cally significant. As this simple quasi-example 
shows, TECO was nothing if not terse. Fairly 
complex loops and other command sequen- 
ces could be written in TECO, and mostly 
looked like line noise. TECO was one of 
the first languages to spawn the practice of 
handing someone a one-line string of near 
gibberish and asking with a grin, ‘‘tell me 
what it does.’”’ Nonetheless, TECO made it 
onto Jean Sammet’s list of known program- 
ming languages sometime in the late 
1960s.* 

There have been innumerable comments 
over the years about how obscure the TECO 
language is. Few would dispute the premise 
that it is easier to write than to read. As an ed- 
itor however, its brevity was one of its advan- 
tages. Regular users quickly learned the more 
frequent command sequences and did not 
even need to think about them. Especially 
after WYSIWYG editors became common, 
the claim that ordinary users could only 
handle verbose, line-oriented editors disap- 
peared. This was hotly debated within DEC 
for some years, pitting developers against 
the business and marketing folks. Today, if 
we considers all the obscure keystroke 
sequences available in the most commonly 
used software, with modifiers Control, 
Alt, Shift, and others, TECO seems almost 
simple. 
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Anecdotes 


TECO moves to new machines 

Within a few months, TECO was being used 
in several PDP-1s around MIT. Besides the first 
one in RLE, there was one being used for anal- 
ysis of bubble chamber photographs by Profes- 
sor Martin Deutsch. In my last undergraduate 
year or so, Deutsch hired me to do further 
work on TECO and some other programming 
tools that I had developed. 

A PDP-1 had also been installed in the new 
Tech Square building where Marvin Minsky 
had his AI lab. This was also where the first 
DEC PDP-6 at MIT would be installed in 
1965, and it become the first machine to 
which TECO would be ported. I did not do 
that port myself; it was done by Stewart Nel- 
son, Richard Greenblatt, and Jack Holloway, 
who had been using the AI PDP-1 and were 
among the first to get their hands on the 
new PDP-6. Some enhancements had already 
been made to the PDP-1 version by the AI 
group, and it was used heavily there. Hence, 
porting it to the new PDP-6 was an urgent 
project. I had earlier been offered a part- 
time job by DEC to do that port for their 
new, still-in-development machine, but I 
was trying to finish my senior year without 
flunking out, so wisely I declined. 

PDP-1 TECO was written in assembly lan- 
guage, and simply recompiling the source, 
even with a few edits, was impossible. How- 
ever, the PDP-6 had a far more powerful and 
general instruction set, so much of TECO 
could be simply (if only manually) translated 
instruction by instruction while still remain- 
ing in assembly language. One big difference 
was the change of character set. The PDP-1 
used an encoding called FIO-DEC (the Frie- 
den paper tape code as adopted by DEC). 
The PDP-6 used a Teletype Model 35 or 33, 
which supported ASCII (upper-case only). 

Another enhancement begun in the AI PDP- 
1 TECO and made fundamental on the PDP-6 
was to use the display to show the text around 
the editing point. This was not yet on-screen 
editing in the current sense; commands were 
still entered and echoed on the console tele- 
type, but the feedback to the user was much 
enhanced. It wasn’t until some years later 
that CRT-based terminals became common. 
Until then, most users could only use TECO 
in the traditional way on a hard-copy device. 

Many other enhancements were made in 
the next few years, fostered by the PDP-6’s 
much larger memory, greater power, and pro- 
gramming ease. The command set for that 
version can still be found with a Web search 
today and, as far as I know, was by far the 
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most complex version of TECO ever in com- 
mon use. Although there were numerous 
other ports for other machines in the follow- 
ing years, most of them were much more 
basic and similar to the PDP-1 version. Even 
the version of TECO included by DEC in its 
initial release of the PDP-10 (DecSystem-10) 
was more basic. Bob Clements (at DEC at 
the time) had taken a relatively early version 
of the PDP-6 AI TECO, stripped it down to re- 
move things that were not available on most 
installations (e.g., the expensive CRT display) 
or to timesharing terminal users, and that be- 
came the version shipped by DEC on the 
PDP-10 and later PDP-6 installations. It was 
also the version that came into my hands 
when Bolt Beranek & Newman (BBN) got a 
PDP-10 (1969), which I would evolve from 
then through about 1986. 


The Spirit of Open Source 

From the time of TECO’s original develop- 
ment through the PDP-6 port, we were all 
happy to have DEC or anyone else take the 
programs we had written to use or even sell. 
For an undergraduate like myself, having peo- 
ple use and like them was the reward. Besides, 
nobody had any idea how or whether soft- 
ware could be copyrighted or otherwise pro- 
tected. This was the open-source model in 
action long before that term came into use. 

Starting with the PDP-6, TECO was 
included in the base software set of every sys- 
tem that DEC offered, including the PDP-8, 
PDP-11, DecSystems 10 and 20, and VAX/ 
VMS. It also continued to be heavily used 
and enhanced by the hackers” in Minsky’s 
AI lab, eventually including Richard Stall- 
man. In the early to mid-1970s, Stallman 
would make some key enhancements to 
TECO that allowed it to become a fully inter- 
active, WYSIWYG-style onscreen editor. A 
key piece of this implementation was an en- 
hancement where an individual keystroke 
could be made to immediately invoke a 
macro (i.e., a function to be executed). This 
included the normal graphic keys, so typing 
an a in normal text entry mode invoked a 
function to insert a into the buffer and, of 
course, update the onscreen display. This 
resulted in many users creating keystroke- 
triggered editing operations, and before 
long, an effort was made to collect the most 
useful of them into a set that could be docu- 
mented and used by others. This became the 
original Editor Macros (Emacs). 

TECO would continue to be the text en- 
gine for EMACS for several years, but it was 
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ultimately replaced by a Lisp-like text manip- 
ulation language known as Emacs-Lisp. 

Several versions of TECO for soft-copy ter- 
minals would also be done, including one by 
me called VTECO for TENEX and TOPS-20. A 
number of dialects of the TECO command 
language also grew up, as various branches 
of development and evolution continued in 
different places. The DEC Users Group 
(DECUS) had a TECO Special Interest Group 
(TECO-SIG). Although DEC products contin- 
ued to be where TECO was most consistently 
available and used, it was ported to many 
other products as well. The lineage of many 
of these versions is now difficult or impossi- 
ble to determine. 


Reflections 

Clearly, TECO has had numerous users 
over the years. A relative few wrote or 
attempted to write actual programs in 
TECO. One of my early exercises was to 
write an arithmetic expression compiler in 
TECO. This would take an expression like 
x=a+ (b—c)*3/d and translate it to a se- 
quence of PDP-1 assembler instruction to per- 
form the computation. I never attempted to 
make it a practical compiler though; it was 
mainly a way to test the completeness of 
the TECO command set and a cool hack. 
Other known TECO programs included an 
early email interface—a set of TECO macros 
from Larry Roberts at ARPA that let you selec- 
tively read messages from your email inbox. 

Although this level of TECO hacking was 
unusual, many users would come up with 
their own customizations in the form of 
handy command sequences that could be 
saved as TECO macros and quickly invoked 
in an ordinary editing session. Unlike the 
keystroke captures in some of today’s edi- 
tors, TECO macros were plain text, so they 
could be edited like any other text to 
debug and enhance them. With that and 
the ability to use programming constructs 
like loops and conditional searches at any 
time, TECO offered capabilities that many 
former TECO users, myself included, find 
lacking in contemporary editors. Things I 
used to do in TECO on the fly must now be 
done more laboriously, or if that isn’t tolera- 
ble, not done in the editor at all but rather 
using other tools such as Grep, Sed, Awk, 
and Perl. 

For anyone who would like to run TECO 
now, at least occasionally, there are versions 
available on the Web for most common 
systems.° 
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